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(57) L 'invention est une inteiface conun andde & base 
Web qui est utilis^e pour g6rer les stances 
multidestination 4 protocole Internet entre plusieurs 
utilisateurs. Une interface utilisateur permet de saisir des 
informations pour ordonnancer une stance conference et 
une interface idseau permet de saisir les informations sur 
les utilisateurs qui participent k la conf6rence. Les 
informations d’ordonnancemcnt de la conference et les 
informations sur les utilisateurs qui participent e la 
conference sont conscrvees dans une base de donnees. 
Un gestionnaire de pontage audio re 9 oit des instructions 
de riitterface utilisateur et 4 acc^s aux informations 



(57) A web-based controlled interface for managing an 
internet protocol multicast session between a plurality of 
users. A user inteiface provides for the inputting of 
information to schedule a conference session and a 
network interface provides for the inputting of 
information cmesponding to users participating in the 
conference. A database stores the conference scheduling 
information and the information corresponding to the 
users participating in the conference. An audio bridge 
manager receives instructions from the user interface and 
accesses information stored in the database for 
instructing an audio bridge to establish a telephone 



M 



Industrie Canada Industry Canada 



fOOCIO; <CA. 



^4Qe78Al.L> 



Available Copy 




t 



OPIC 

Ovptci Dt LA HtOPRlftTt 
INT&LLiCTUBLLI DU CaNADA 




Cl PO 

Canadian Intcllbctual 
pROPBRTT OpPICB 



(2i)(Ai) 2,240)878 

(22) 1998/06/17 
( 43 ) 1998/12/27 



stockdes dans la base de donndes qui sont ndcessaires au 
pont audio pour^ablir une connexion tdtdphonique avec 
lesutilisateurs participants. Une adresse multidestination 
IP est produite et est utilisde pour transmettre les 
informations multimddia entre les participants i la 
conference par rinterm^iaire d*un r^seau 
multidestination a protocole Internet. 



connection with the user participants. An IP multicast 
address is generated which is used to transmit 
multimedia information among the participants in the 
conference over an internet protocol mulitcast network. 
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Block coding scheme for reduction of peak 
to mean envelope power ratio of multicarrier 
transmission schemes 

A.E. Jones, T.A. Wilkinson and S.K.. Barton 



Indexing terms: Frequency division multiplexing. Block codes 



A block coding acticmc for the feduction of the peak to mean 
envdope power ratio of multkanier transmission idiemes such as 
OFDM is proposed. The principle of the scheme is illustrated 
with the spedne example of a fuiir-cainer signal. It is shown that 
the peak to mean envelope power ratio of this signal can be 
reduced from 6.02dB to 2.48dB with a 3/4 rate biodi code. The 
applicatioo of the block coding prindple with flexibility such that 
the coding rate can be traded against peak to mean envelope 
power ratio is ilhutrated with the example of an dght<carner 
signal. 

Introduction: Multicarricr transmission schemes such as OFDM 
(orthogonal frequency division multipfexing) (1) have been pro- 
posed for many dilTerent types of systems from DAB (digital 
audio broadcasting) [2] to radio LANs Oocol area networks) (3]. 
The advantage of such schemes is that unlimited transmission 
rates are theoretically possible in highly time dispersive channels. 
The disadvantage is that multicarrier signals exhibit a high peak to 
mean envelope power ratio (PMEPR). Hence, linear and conse- 
quently inclTident ampliTicrs arc required for the amplification of 
these signals to avoid distortion and spectral spreading. In addi- 
tion to this, some band regulations specify a PEP (peak envelope 
power) limit for a given band, and cousequently the choice of a 
multicarher transmission scheme, for a system, does not make the 
most of this type of power limit. 

There is cleariy a necessity to limit the PMEPR of multicarricr 
signals. One method, which was proposed in [4], is amplitude lim- 
iting the multicarricr at the point of generation. In this Letter, an 
allenutive method is proposed based on block coding the data 
prior to modulation in such a way as to avoid excessive PEPs. 

Block coding scheme: To illustrate the principle of the proposed 
scheme, consider a ihulticarrier transmitter consisting of a data 
source and serial to parallel converter providing N streams of data 
that are modulated BPSK. (binary phase shiR keying) on to A car- 
riers with uniform orthogonal frequency spacing equal to the sym- 
bol rate on the individual carriers /,. If the outputs of these 
modulatois are combined the composite signal is given by 

n=N 

,(() = ( 1 ) 

nsl 

where N is the number of carriers, d, is the data applied to (he nth 
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1 Envelope power of four-carrier signal for all possible data words 



carrier,/; is the frequency offset of the nth carrier frequency from 
the centre frequency and b. is ^ initial phase of the nth carrier. 
In OFDM, the modulation is usually performed with an FFT (fast 
Fourier transform) [1]. For simf^ity, we assume that the initial 
l^iases of the carriers are rero, whidi b the case when FFT 
modulation b used. The envelope power of the multicarricr signal, 
p{t), b simply s(r)s*(/). If the power in the individual carrier* b 
nonnalised to 1 W, then the maximum PEP b JV*W. The PEP dur- 
ing a symbol period depends on the datum d„, applied to the car- 
riers, or data word d, whicb b an TV-bit binary number. I'he 
envelope power a four-carrier .signal as a function of time, for 
all possible 4 bit data words d inaeasing sequentiaDy from 
*0000’,„ to IS^,,, ‘MIIV,. b plotted in Fig. 1. The p^ to mean 
envek^ power ratio of thb signal 6.02dB. The PEPs during a 
symbol period for all possible data words d are given in Table 1 . 

Table 1: PEP during symbed period for all possible data words 
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It cun be seen from this Table that four words result in the maxi- 
mum PEP of 16.00W and another four words result in a PEP of 
9.4SW. It is clear that we could reduce the peak to mean envelope 
power ratio of thb multicarricr signal by avoiding transmitting 
these words. This can be done by block o^ng the data such that 
a 3 bit data word b mapped on to a 4 bit code word such that the 
set of permisable words does not contain those that result in 
excessive PEPs. In thb particular case, the code word set resulting 
from the mapping is an odd parity code. The first three bits of the 
code word, c„ c, and Cj, are the three bits of the data word, di, dj, 
and di, and the fourth bit is the odd parity check bit. The code 
word c is applied lu the cairiers. The envelope power of the 
encoded si^ial, as a function of time for all possible 3 bit data 
words increasing sequentially from ‘000V„ to 1^, is 

plotted in Fig. 2. The PMEPR of thb signal b 2.48dB, a reductiem 
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of 3.54dB from that without block coding. Such a reducdon will 
enable reduced noolinear distortion and spectral regrowth and/or 
increased ampUfter efficiency. Such a reduction would also allow a 
system using this multicarrier signal to have a 3.4SdB tncreasod 
average transmit power in a hand with a PEP limit. 




ddec fwfTT 



Ffg. 2 Envebpt power of block coded signal for all possible data words 

This reduction of the PMEPR is at the expense of an increase in 
bandwidth for the same data rate ami a reduction in the energy 
per transmitted bit for the same transmit power. The 

increase in bandwidth is small and, in comparison with multicar- 
rier schemes with single carrier schemes, this is offset by the high 
spectral efficiency of multicarrier st^emes. The reduction in energy 
transmitted per bit is also small and this could be offset by the 
high spectral efficiency of the mulucarrier schemes. The reduction 
in energy transmitted per bit is also small and this could be offset 
the error detcction/coirection potential of the block loading, if 
can be exploited. 




ms 

Hr . 3 Resulting to mean mvehpe power ratio as function of number of 
permissible code words (monber of possible code words) 

Finally, we consider an eight<carrier signal, to illustrate how the 
block coding principle can be applied with flexibility such that the 
coding rate can be traded against the PMEPR. The resulting peak 
to mean envelope power ratio as a function of the number of per- 
misaiblc code words CW^ divided by the number of possible 
code words CW^ is plotted in Fig. 3. If the number of permissi- 
ble code words equals the number of possible code words there is 
no block coding and PMEPR = 9.03dB. If half the possible code 
words are permissible, corresponding to a 7/8 rate o^e, PMEPR 
= 4.4SdR, a reduction of 4.5ftdB. If a quarter of the passible code 
words are pennissible, corresponding to a 3/4 rate code, PMEPR 
- 3.0 1 dB. a reduction of 6.02dB. It is obvious that signilicant 
reducticHis in PEP are possible. However, we have shown that the 
necessary code sets exist but not how to perform the encoding and 
decoding. This may be realisable in comlnnatorial logic or it may 
require a look-up table depending on the specific case. This aspect 
is being investigated. 

Conclusions: A block coding sdieme for the reduction of the 
PMEPR of multicarrier transinission schemes such as OFDM has 
been proposed. The principle of the scheme has been illustrated 
with the specific example of a four-carrier signal. It has been 
shown that the PMEPR of this signal can be reduced from 6.02dB 
to 2.48dB with a 3/4-rate block code. The apfrfication of (be block 
coding principle with flexibQity such that the coding rate can be 



traded against peak to mean envelope power ratio was illustrated 
with the example of an eight carrier signal. The Letter has concen- 
trated on BPSK modulation on the individual carriera but the 
tedinique is generally applicable with QPSK. modulation or other 
coherent modulation seines. 
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Decision feedback multiple-symboi 
differential detection with MRC diversity 

M. Fujii and A. Yamashita 



Indexing terms: Cdbdar radio. Diversity reception. Deieeioe 
circuits 



The authors propose decision feedback multiple-symbol 
diflerential detection with maiimal ratio cotnbinnig the diversity 
of r/ 4 shiA DOPSK. Its performanoe is then evaluated in a 
combined additivc-white-Oaussian-noise, Kaylagh-Tading and 
cochannel-interrereaoe environment by computer stmolation. We 
show that the perforaianoe of this stnu:ture b superior to 
conventional schemes under both the cuoditions of static and fast 
fading in the piesence of cochannd interference. 

Introduction: In digital cellular systems, the transmission perform- 
ance b severely dbtorted by Rayleigh fading and/or cochannd 
interference (CCl). The combinatioa of differential detection (DD) 
and postdetection selection combining (SC) diversity b one of the 
most practical schemes to combat thb degradation. 

However, it is well known that the performance of differential 
QPSK is inferior to coherent QPSK by 2dB in an additive white 
Gaussian nobe (AWGN) channel. One method of improving the 
DD peiformanoe employs multiple-symbol diflerentid detection 
(MDD). There are various detection methods in MDD. Among 
these, decision feedback multiple-symbol differential detection 
(DF-MDD) [1] is simpler than the other methods based on maxi- 
mum likelihood estimation. Furthermore, a simpler DF-MDD 
structure, known as generalised differential detection, is proposed 
(2]. The performance of MDD may, however, degrade for fast-fad- 
ing channels because of the degradation of the >l-order detector. 
On the other hand, it b known that maximal ratio combining 
(MRC) diversity is superior to SC diversity because it improves 
the signal/noise ratio. Also the MRC diversity gain b larger than 
that of the SC in a fast-fading duumel [3] or in a CCI channel. 

We expect that by combining diversity branches we can mitigate 
the degradation of MDD due to fast channel variation. The com- 
bination of DF-MDD and MRC diversity can produce some gain 
compared to the conventional combinalioiis of DD with SC^ or 
DD with MRC in both static and fading channels in the presoxx 
of CCl. We propose the combination of DF-MDD and MRC 
diversity to further improve the bit-error-rate (BER) performance 

2099 



ELBCTRONICS LETTERS 8th December 1994 Vol.30 No. 25 



Best Available Copy 





CA 0224087« 1998-06-17 



Internet Based IP Multicast Conferencing and 
Reservation System 

ABSTRACT OP THE DISCLOSURE 

A web-based controlled interface for managing an 
internet protocol multicast session between a 
plurality of users. A user interface provides for 
the inputting of information to schedule a conference 
session and a network interface provides for the 
inputting of information corresponding to users 
participating in the conference. A database stores 
the conference scheduling information and the 
information corresponding to the users participating 
in the conference. An audio bridge manager receives 
instructions from the user interface and accesses 
information stored in the database for instructing an 
audio bridge to establish a telephone connection with 
the user participants. An IP multicast address rs 
generated which is used to transmit multimedia 
information among the” participants in the conference 
over an internet protocol mulitcast network. 
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INTERKET BASED IP MULTICAST CONFEREKCINO AMD 
RESERVATION SYSTEM 



FIELD OP INVENTION 

The present invention relates generally to 
internet communication systems and more particularly 
to a web-based interface for creating and managing an 
internet protocol multicast conference between a 
plurality of users. 

BACROROUND 

Presently, an Internet Protocol IP datapacket 
sent over an internetwork inceraet may have a unicast 
address used to transmit the packet from a source to a 
"s ingte' ‘r edpl"ent or ~a'”broadcas t “a’ddres s“"us ed ”t*o" send" 
the packet from a source to an entire subnetwork. The 
unicast protocol is limited to one source and one 
recipient configuration. The broadcast transmission 
protocol sends the data packet to a recipient 
regardless of whether or not the recipient within the 
subnetwork wants to receive the packet with the number 
of receivers being limited by the amount of bandwidth 
available to the source. 

IP Multicast Routing is an alternative to unicast 
and broadcast transmissions. Multicast Routing enables 
a source to deliver a single copy of a data packet to 
multiple recipients that have been configured as 
members of a multicast group either within the same 
subnetwork or across various subnetworks. The 
multicast backbone or Mbone is an interconnected set 

of subnetworks that supports the delivery of IP 
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multicast traffic. The Mbone uses a group address, in 
a class D address format which ranges from 224.0,0.0 
to 239.255.255.255 to fill the destination address 
field of an IP packet header to route the packet 
across networks. Once a user joins a particular 
multicast session, IP packet traffic is delivered to 
all members of the group by the network address 
infrastructure. By using the Mbone, only a single 
copy of a multicast message or data packet is sent 
over any node within a network. Copies of the message 
are; made only where a transmission path diverges at a 
network router. In this manner, network transmission 
bandwidth is conserved. 

In Multicast Routing, a Group Membership Protocol 
is used by the network routers to learn which users, 
attached to the router’s subnetworks, belong to a 
particular Multicast session. A user transmits a 
group membership message notifying the network that 
the user wishes to receive IP traffic sent among 
participaTibs — in" that particular group". In' thrs“ 
manner, a user can initiate the process of connecting 
to a multicast group session thereby alleviating the 
initiator of the session from maintaining a list of 
participants. A drawback associated with current 
multicast sessions is that they are receiver based in 
that participants receive information from the group, 
but cannot perform collaborative or interactive tasks. 
Another disadvantage associated with current multicast 
transmission is that audio communication is subject to 
packet delays, echos and packet loss. Moreover, a 
multicast session is available to any user that 
obtains the Multicast address, thereby making security 
among participants almost impossible. In addition, 
currently a tool does not exist where users can access 
a web*based interface for scheduling a multicast 
session among a particular group of users which also 
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provides an audio connection to only those users 
in the multicast conference session. 
Accordingly, there exists a need for an internet web- 
based interface, accessible to all users having a web- 
browser, for scheduling, managing, securing and 
maintaining an IP multicast session for use as a 
conferencing and application sharing tool. 

8CKNARY OP IMVSNTZON 

A system manages an internet protocol multicast 
network conferencing session where a plurality of 
users receive transmitted multimedia information. A 
network interface resident on a web- server manages a 
conferencing session. An interface accessible via a 
web-browser is adaptable to receiving information 
related to a conferencing session. An audio interface 
establishes an audio connection among the conferencing 

icipants. A multicast interface transmits 
multimedia information via an internet protocol 

network. — — — — - - . . _ 

BSIBP DESCRIPTION OF DRAWINGS 

^^9’ 1 is a block diagram overview of a system in 
accordance with an embodiment of the present 
invention. 

Pig. 2 is a flow chart illustrating an exemplary 
process of initiating a multicast session. 

^^9- 3 is a flow chart illustrating an exemplary 
process of activating a multicast session. 

Fig. 4 is a flow chart illustrating an exemplary 
process for a user joining an activated multicast 
session. 

DETAILED DESCRIPTION 

Referring to Fig. i, the system lO in accordance 
with the present invention employs a session manager 
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20, a mulcicast address generator 30, a directory 
manager 40, an audio bridge manager 50, a session 
activator 60, and an audio bridge 70 for setting-up, 
managing and participating in a multimedia session as 
well as allowing users to engage in multimedia Closed 
User Group (CUG) activities such as application 
sharing among a plurality of users. The system 
interconnects the internet 94 and IP multicast network 
95 as well as the Plain Old Telephone System (POTS) 
network 75 to establish a multimedia session. 

A multicast conferencing session is an 

interactive audio, video, and/or data session shared 
among a plurality of users. For the purposes of 
explanation, Fig. 1 references users 80 and 90, 
however it is understood that the present invention 
can establish a conferencing session with numerous 
participeuits not shown in Fig. 1. A session initiator 
or host 80 having a computer 81 and a phone 82 
accesses the conferencing service web page via session 
manager — 20 ■using" “their "“compu ter "SIT" to access" an 
internet web browser to reserve a session. As a 
session participant, user 90 having a computer 91 and 
a telephone 92 also accesses the conferencing service 
web page via session meuiager 20 using computer 91. 
The front-end of the session manager 20 allows host 80 

as well as participants, such as user 90, to be 
authenticated by the system for security purposes. At 
session reservation time, host 80 provides session 
manager 20, through accessing of an Hypertext Markup 
Language (HTML) page, with all information necessary 
to activate a session. This information may include 
title of the conferencing session, start time of the 
session, stop time of the session, duration of the 
session, repeat times of the session, number of ports 
or participants in the session, bandwidth required, 
media types to be employed, etc. These addresses are 
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generated automatically by multicast address generator 
30 based on the date, time, duration and repeat times 
entered by host 80. Alternatively, the IP multicast 
addresses needed to initiate and maintain the 
conferencing session, as well as ports required for 
different media types, can be entered manually by user 
80 when initiating a conference using session manager 
20. Multicast address generator 30 automatically 
generates an IP multicast address by retrieving the 
next unassigned address from a list of reserved 
multicast class D address blocks. The information 
received from host 80 is sufficient to create a 
Session Description Protocol (SDP) file. Once the 
session information is saved, a session ID and access 
code are returned to host 80 as the initiator of the 
conference. Profile data associated with host 80 can 
be retrieved from directory manager 40 to prepopulate 
certain fields when initiating a conferencing session. 
This profile information associated with host 80 may 
include — namer" e-mai-1 addressr telephone- number, — 
company name, etc. Once the session is scheduled, all 
data pertaining to the session is stored in directory 
manager 40 corresponding to a session ID generated 
uniquely by session manager 20 for that particular 
conference. In addition, once a session has been 
scheduled, host 80 can invite additional participants, 
such as user 90, via an alternative communication 
mechanism such as e-mail and/or phone, thereby 
notifying them of the session title, description, 
date, start time, stop time, session ID and most 
importantly, the session access code so that user 90 
may access the conference. In this manner, session 
security is maintained since only participants with a 
valid session ID and access code can join a multicast 
conference . 
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To activate the audio portion of a conference, 
session activator 60 communicates with audio bridge 
manager 50 to set up a bridge conference accessible to 
participant 90 and host 80 based on the session ID 
retrieved from directory manager 40 for a particular 
conference. Session activator 60 includes a process 
that continuously queries directory manager 40 for the 
start dates and times as well as the repeat dates and 
times of the scheduled sessions and activates the 
session if it matches the current date and time. 
Participant 90 enters the session ID, access code, 
their name and phone number and session manager 20 
validates that the entered information is correct . 
Session manager 20 then retrieves information 
associated with that particular conference session 
from directory mauiager 40. Session manager 20 
communicates with audio bridge manager 50 to join 
participant 90 into the audio session corresponding to 
the particular session ID. Session manager 20 
— txansmirts — the- -phone-number of" parfi-cipant 90 to “the 
audio bridge manager 50 which instructs audio bridge 
70 to call phone 92 of participant 90 thereby 
completing the audio connection via a conventional 
POTS network 75. A similar process occurs with 

respect to phone 82 for host 80 and the completion of 
a host's audio connection. 

Once a voice connection is established between 
participant 90 and audio bridge 70, an SDP file is 
dynamically created from information retrieved from 
directory manager 40 pertaining to the conferencing 
session. The SDP file is in a format that the viewer 
application understands and can process in order to 
provide a user with the multicast data. This 
information is returned to the web-browser used by 
participant 90 with the MIME Content-type 

applicaCion/x-Bdp. This enables the automatic 
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launching of a viewer application from the 
participants browser in a conventional manner. 

Information transmission between session manager 
20 , multicast address generator 30, directory manager 
40, audio bridge manager 50, and session activator 60 
within the system can be through a Transmission 
Control Protocol/Intemet Protocol (TCP/IP) socket 
connection over the internet, an Asynchronous Transfer 
Mode connection, a serial line connection, a standard 
modem or other similar transmission medium. Session 
manager 20 communicates with multicast address 
generator 30, directory manager 40, and audio bridge 
manager 50 through the use of a Common Gateway 
Interface (CGI) program residing on the web server. 
If multicast address generator 30, directory manager 
40 or audio bridge manager 50, reside on a different 
machine than the web server, then communication 
between the conponents can be made from the CGI 
scripts to any remote mechanism such as Remote 
"Procedure— Cairl- (RPC)’. — Each' CGT • program" parse's 
parameters from the URL or a submitted foinn (using 
methods such as GET or POST) received from the user's 
browser. 

As described briefly above, session manager 20 
functions as an entry point to the conferencing system 
and a central point for memaging, coordinating and 
communicating with other session participants. 
Session manager 20 resides on an internet web server 
making it broadly available to all internet users. 
Users 80 and 90 access an HTML page, which serves as a 
gateway to session manager 20, through a Web-browser 
on a user's desk-top computer. Host 80 schedules a 
particular conferencing session by inputting 
infoinnation via the HTML page. 

Directory manager 40 consists of a database that 
includes various participant information associated 
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with the scheduling of a particular conferencing 
session received from session manager 20. For 
example, stored information may include a 
participant's name, company, e-mail address, telephone 
number, telefax number, etc.. Directory manager 40 
also stores multicast attributes associated with a 
particular conferencing session including a session 
ID, session title, session start time, session finish 
time, multicast range, media types and formats used 
within a session and corresponding IP multicast 
addresses and ports, quality of service information, 
bandwidth, as well as information corresponding to 
active conferencing sessions and their participants. 
This infonnation is received from the initiator of the 
session via session manager 20 . The architecture 
associated with directory manager 40 is implemented 
based on a mechanism for internet users to query and 
manage an arbitrary database of hierarchial 
attribute /value pairs such as the Lightweight Director 
—Access- Protocol- -(tiDAP) -as- described- in- What i-s- a 
Directozy Service? end What is LDAP , from the SLAPD 
and SLURPE /administrators Guide, University of 
Michigan, Release 3.3, April 30, 1996. Alternatively, 
data stored in directory manager 40 could also be 
stored in a commercial database and retrieved. 

Session manager 20 accesses the information 
stored in directory manager 40 through the use of CGI 
. Various tools are available to accomplish 
this task, for example. Rogue Wave dbTools.h++ and 
tools. h++libraries to make database calls from C++ CGI 
scripts. Alternatively, new information can be added 
to the database in directory manager 40 as well as 
updating and deleting existing information through 
ESQL commands or other tools performed by a 
coordinator or supervisor with special access 
privileges. Each conference session as well as its 
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attributes are queried using a session ID as the 
primary key. The session subscribers register with 
directory manager 40 prior to the initiation of the 
conference session. A1 tentatively, a conferee can 

register themselves or other conferees with directory 
manager 40 at the time of initiating a conference 
session. Table 1 shows exemplary subscriber 

information stored in a database of directory manager 
40. 



Participant 

Marne 


User ID 


PasflMord 


Participant IP 
Address 


Participant e-nail 


Participant 
Phone No. 


Jane Doe 


JAD 


««««*#« 


13S.15.i5.23S 


jdainc.coto 




John Doe 


JOD 




135. 16. 4S, 123 


jdoeftany .con 





Table 1 

Audio bridge mauiager 50 receives instructions 
regarding the multicast conference session from 
session manager 20. Audio bridge manager 50 is 
connected to audio bridge 70 through a communications 
protocol such as DATAKIT and contains all the API's to 
communicate status and control to audio bridge 70 . 
Audio bridge manager 50 shares the same database with 
session manager 20 and accesses all necessary 
P® 2 ^ticipant session information. Communication 
between session manager 20 and audio bridge manager 50 
are implemented via RPC where procedure calls are made 
across the network using CGI scripts. In this manner, 
all status changes, for example a participant 
terminating its POTS connection, are communicated from 
the audio bridge 70 to audio bridge manager 50 where 
HTML screens get updated dynamically in session 
manager 20 via seirver push technology. The web server 
dynamically updates data to the browser without the 
browser explicitly requesting to receive the data. At 
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conference session activation time, an audio session 
gets activated on audio bridge 70 through 
communication between session manager 20 and audio 
bridge manager 50. An IP multicast application server 
resident in multicast network 95 starts transmitting 
audio, video or data to the IP multicast addresses 
specified at session reservation or activation time. 
In order for host 80 and participant 90 to receive IP 
multicast traffic they must access a multicast enabled 
router. If user 80 and/or participant 90 are not 
connected to a multicast enabled router, they must be 
connected to a gateway server which communicates with 
a multicast enabled router in order for the end user 
to be able to receive multicast traffic. Audio bridge 
manager 50 can reside on either the same web-server 
machine where session manager 20 resides or it may 
also reside on a different machine. 

Pig, 2 is a flow chart illustrating an exemplary 
process of initiating a multicast session and inviting 
partl‘cipant'8 to~the "session using t he“ syst em “described 
with reference to Fig. 1. The process begins at step 

200 when the session initiator or host 80 accesses the 
web-based interface via session manager 20 using their 
web-browser. Host 80 inputs relevant session 
information which is authenticated by the system at 
step 201 based on a user password authentication 
process. If authentication fails, an error message is 
sent to host 80 *s web-browser at step 202 and the 
process exits at step 210. If authentication at step 

201 is confirmed, the process continues to step 203 
where host 80 requests to reserve a multicast session 
and is provided with an HTML page to schedule a 
conference. The host 80 inputs the conferencing 
session parameters as described above, which are 
necessary to initiate the conferencing session at step 
203. In step 204, the session manager 20 communicates 
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with the multicast address generator 30 transmitting 
the session's scheduled date, start time, and stop 
time. An IP multicast address from the multicast 
address generator 30 is also received by user 80 at 
step 204 , In step 205 all data relevant to the 
conferencing session is stored in directory manager 40 
and associated with the unique session ID generated by 
session manager 20 in step 204. At step 206, host 80 
is provided with the unique session ID and access code 
generated automatically by the session manager 20. At 
step 207, session access information along with the 
relevant user information such as the date and time of 
the conference is transmitted to participant 90 via 
session manager 20. Alternatively, the initiating 
user cam notify participant 90 as well as other 
participants via some other communication mechanism 
such as E-mail or phone. 

Fig. 3 illustrates an exemplary process of 
session activation using the system described with 
■reference to“Ftg. It The- session is— activated by- 
session activator 60 at the date and time entered 
during conference scheduling. In step 301, session 
activator 60 obtains the previously stored information 
for the particular conferencing session from directory 
manager 40. Session activator 60 notifies audio 
bridge manager 50 through RPC calls to the audio 
bridge manager 50 from CGI scripts to activate a new 
audio session on the audio bridge 70 associated with 
the particular session ID at step 302. In step 303 
session activator 60 notifies directory manager 40 to 
update the status of the present conference session to 
active. The process then exits at step 304. 

Fig. 4 illustrates a flow chart of an exemplary 
process of participant 90 joining an activated 
multicast session using the system described with 
reference to Fig. 1. Participant 90 accesses session 
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manager 20 through a web browser. Participant 90 
inputs their user name and password to get 
authenticated by the system. At step 401, participant 
90 reguests to join a conferencing session and thereby 
retrieves an HTML page to enter the session ID and 
access code. At conditional branch 402, session 
manager 20 atten^ts to authenticate the user 
information by querying directory manager 40 to 
validate the session ID and access code provided by 
the participant at step 401. If validation fails at 
step 402, an error message is provided to participant 
90 at step 403 and session manager 20 denies access to 
participant 90. If a session is valid, the process 
continues to step 404 where another conditional branch 
is perfomed to determine if the session authenticated 
at step 402 is currently active. This active session 
conditional branch is performed by session manager 20 
calling an API on audio branch manager 50 to check 
whether the session is active. If the conferencing 
session is not active, an error message is provided to 
the user at step 405 and the process exits at step 
411. 

If the conditional bramch at step 404 is 
satisfied and the session is determined to be active, 
session manager 20 retrieves the information 
associated with that particular session from directory 
manager 40 at step 406. In step 407, session manager 
20 calls a CGI script on the web- server used by 
participant 90 which begins communication with audio 
bridge manager 50 through RPC and sends the audio 
bridge manager 50 the phone number of participant 90 
by calling appropriate API's. The voice connection 
for participant 90 is established through audio bridge 
manager 50 communicating with audio bridge 70 to call 
telephone 91 associated with participant 90 using 
bridge interfaces at step 408. Once participant 90 
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has successfully Joined the audio session, session 
manager 20 generates an SDP file based on the data 
retrieved from the directory manager 40 with MIME 
Content-type application/x-sdp and sends the file back 
to the web-browser used by participant 90 at step 409 . 
In step 410, the web-browser associated with 
participant 90 launches an IP multicast viewer 
application upon receiving the SDP file allowing 
participant 90 to join the multicast session at the IP 
multicast address specified in the SDP file. 
Participant 90 receives the multicast data transmitted 
among the session users. This viewer application can 
be configured as a plug in or a helper application in 
the participant’s browser. 

A participant may leave the session at any time 
where they will be dropped from the POTS network 75 
audio connection with API calls made to audio bridge 
manager 50 by session manager 20 and the viewer 
application is terminated at which point the process 
exits at step 411. AXternat-avely, tire" sesmbn may be “ 
terminated at the indicated stop time of the scheduled 
session originally entered by host 80 or can be 
terminated by the host at einy time. 

Through the use of a web based controlled 
xnterface, a multicast conference session is created 
and managed among a number of participants, a unique 
session ID and access code ensures a closed user group 
enforcing access restrictions for conferencing 

security. An audio bridge manager coordinates 
communication among participants using an audio bridge 
to establish an audio connection using the POTS 
network. m this manner a multicast session can be 
established among a particular group of users which 
provides an audio connection to those users 
participating in the multicast conference session. 

The multicast conferencing system in accordance with 
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the present invention utilizes a user interface and a 
network interface. The user interface allowing a 
participant to set up a multicast session while the 
network interface retrieves information from 
appropriate user databases. 



70CID: <CA 2240e7eA1J_> 




CA 02240878 1998-06-17 



15 



What is claimed ist 

1. An apparatus for managing interactive 
conferencing among a plurality of users using an 
internet protocol multicast network comprising: 

a network interface resident on an internet Web- 
server for managing said conferencing session; 

a user interface, accessible via an internet web- 
browser, communicating with said user interface, 
adaptable to receiving information related to a 
conferencing session; 

an audio interface receiving instructions from 
said user interface and establishing an audio 
connection among said plurality of users; and 

a multicast interface receiving instructions from 
said user interface and transmitting multimedia 
information vi'a' ~sa*id" infem'et protocol murticast 
network among said plurality of users participating in 
said conference, 

2. The apparatus of claim 1 wherein said user 
interface is resident on an internet web -server and 
adaptable to retrieving scheduling information 
corresponding to said conference, 

3 , The apparatus of claim 1 further including a 
database for storing information pertaining to said 
plurality of users, 

4 . The apparatus of claim l wherein said audio 

includes an audio bridge manager for 
receiving and processing said instructions received 
from said user interface. 
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5 . The apparatus of claim 4 wherein said audio 
interface includes an audio bridge for establishing 
said audio connection with said plurality of users. 

6. The apparatus of claim 1 wherein said user 

interface includes a hypertext markup language page. 

7 The apparatus of claim 1 wherein said user 
interface geaerat.s a aasaion identification cod. 
unique to a particular conferencing seesron. 

e. The apparacua of claii. i wherein ea.d ueer 
interface generates a session access code cossunicated 
to said users for accessing said conferencing session^ 

9 The apparatus of claii. i wherein said 
„,lticast interface cossunicate. with said eulticast 
network via a session description protocol file. 

10. The apparatus of claie 1 wherein said 
i^lticast interface generates a eulticast address for 
transmitting said multimedia information among said 
users during said conferencing session. 

11. A system for multimedia conferencing among a 
pl^SalW of— us^ using - -an Internet- protocol 

multicast network comprising: a user m 

resident on an internet web-server for inputting 
information corresponding to a scheduled conference, 
said interface accessible to said plurality of users,- 
a network interface resident on an internet web-server 
for inputting information corresponding to a plurality 
of users participating in said conference session; a 
database storing said information corresponding to 
said scheduled conference and said information 
corresponding to said plurality of users participating 
in said conference, said database accessible by sai 
user interface to verify conference information; an 
audio bridge manager communicating with said user 
interface and accessing information stored m said 
database; an audio bridge communicating with said 
audio bridge manager and initiating a telephone 
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connection with said plurality of users based on 
instruction received from said user interface; and 

an address generator for generating an IP 
multicast address used to transmit multimedia traffic 
among said plurality of users participating in said 
conference . 

12 . The system of claim 11 wherein said audio 
bridge dials a telephone number associated with each 
of said users participating in said conference. 

. 13. The system of claim 11 wherein said 
Information corresponding to said plurality of users 
participating in said conference session includes an 
internet address associated with each of said users. 

14 . The system of claim 11 wherein said 
information stored in said database is accessed using 
common gateway interface scripts. 

15 . The system of claim 11 wherein each of said 
users receive said multicast traffic via a multicast 
enab'Ted xouteir. — — 

16 . The system of claim 11 further including a 
gateway server connected to a multicast enabled 
router, said users connected to said gateway server 
for receiving said multicast traffic. 

17. A method for managing an interactive 
internet protocol multicast conferencing session 
comprising; 

accessing a user interface via an internet web- 
browser; inputting information relating to said 
conferencing session and user conference participants 
using said user interface; storing in a database said 
information relating to said conferencing session and 
said conference participants; generating an internet 
protocol multicast address associated with said 
conferencing session; and activating a multicast 
session corresponding to said multicast address for 
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transmitting multimedia information over an internet 
protocol multicast network to said conference 
participants. 

18 The method ot claim 17 further including the 
step of authenticating said information corresponding 
to scheduling of said conference session. 

19. The method of claim 17 further including the 
step of establishing an audio connection with said 
conference participants based on information stored in 
said database. 

20. The method of claim 17 wherein said 
conference participants receive said multicast traffic 
from said multicast network via a multicast enabled 

router . . 

21. The method of claim 17 wherein said 

conference participants receive said multicast traffic 
from said multicast network via a gateway server 
connected to a multicast enable router. 

22. The method of claim 17 further including the 
"itep 6f“‘ayh^i«l'ly session descript-ion 
protocol file from information stored in said database 
pertaining to said conferencing session. 

23. The method of claim 22 further including the 
step of launching a viewer application via said user 
interface for transmitting said multicast traffic. 
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FIG. 4 
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